Typical hardware-based rate controllers use a credit scheme in which a fixed number of credits are allocated to a credit bucket at the beginning of each time interval. The rate at which credits are allocated to the credit bucket is defined by the refresh rate and the time interval. If credits are not consumed by packets during the current time interval, then the unused credits are lost and cannot be rolled over to a subsequent time interval. This is known as a “use-it or lose-it” credit scheme. Although use-it or lose-it credit schemes work well to ensure that packet traffic does not exceed the rate that is established by the refresh rate, use-it or lose-it credit schemes often do not work well for rate limiting bursty traffic, where rate limiting involves dropping packets that exceed a specific rate limit. Use-it or lose-it credit schemes do not work well for rate limiting bursty traffic because large bursts of packets often exceed the allocated credits in the current time interval, thereby causing some packets from the burst to be dropped for lack of sufficient credits. While some packets from the burst are dropped because the credits allocated in the current time interval are insufficient, credits in subsequent time intervals go unused during the periods between bursts. Dropping some of the packets from a burst is not a desirable solution to congestion problems.
Traffic that utilizes the Transmission Control Protocol (TCP) is bursty by design. Because TCP is such a widely used protocol for Internet traffic, it is important to be able to accommodate TCP traffic in a rate control scheme such as rate limiting. One feature of TCP traffic is that packets that do not reach their destination are retransmitted from the source. Therefore, any packets that are dropped during a rate control operation at an intermediate network node will be retransmitted from the source. The retransmitted packets consume additional bandwidth in the network and add delay to the packet transmission.
One way to minimize the retransmitting of dropped TCP packets is to buffer the packets before rate control is applied to the packets. Buffering the packets allows bursts of packets to be metered out as credits are allocated during subsequent time intervals without having to drop packets. This type of rate control is generally referred to as “rate shaping.” A disadvantage to buffering packets is that buffer memory adds cost to a traffic control system. Additionally, the buffering is likely to add delay to the packets, which may be unacceptable in time-critical applications such as real-time voice and video applications.
Another disadvantage of typical hardware-based rate controllers is that the parameters of the rate control algorithms (e.g., the time interval and refresh rate) are typically set once and then left alone. This “set and forget” approach works well when the traffic pattern is stable, but, it may not work as well when the traffic pattern tends to be unpredictable.
In view of the desire to provide rate control in a packet-based network, what is needed is a hardware-based rate control technique that accommodates bursty traffic, that does not require dedicated buffer memory, and that is flexible enough to deal with different traffic patterns.